perm filename MSG.MSG[TCH,LSP]5 blob
sn#820392 filedate 1986-07-06 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002
C00003 ENDMK
C⊗;
∂17-Mar-86 2116 RPG Welcome
To: cl-technical@SU-AI.ARPA
...to the world of international standardization. This mailing list
is the forum for private discussions regarding the technical aspects
of the standardization effort. The contents of the messages transmitted
on this list are archived in a private, non-accessible file at SAIL.
If you choose to also archive these messages, please guard their
privacy.
The members of this list are:
rpg
gls%Think.COM
CL-Technical-from-SU-AI@Stony-Brook.SCRC.Symbolics.COM
(= Moon and Weinreb)
Fahlman@cmuc
bawden@mc
bobrow.pa@xerox
rees@mc
griss@hplabs
-rpg-
∂20-Apr-86 0959 RPG Chairman
To: cl-technical@SU-AI.ARPA
Now that things are rolling, I would like to nominate Scott Fahlman as
chairman of this committee. I think we can agree that no one has worked
harder at the development of Common Lisp than Scott, and that we should
unanimously elect him chairman of the technical committee.
-rpg-
∂20-Apr-86 1330 gls@THINK-AQUINAS.ARPA Chairman
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 20 Apr 86 13:30:34 PST
Received: from yon by GODOT.THINK.COM via CHAOS; Sun, 20 Apr 86 16:30:52 est
Date: Sun, 20 Apr 86 16:32 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Chairman
To: RPG@SU-AI.ARPA, cl-technical@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8604201801.AA22752@GODOT.THINK.COM>
Message-Id: <860420163201.4.GLS@THINK-YON.ARPA>
Date: 20 Apr 86 0959 PST
From: Dick Gabriel <RPG@SU-AI.ARPA>
Now that things are rolling, I would like to nominate Scott Fahlman as
chairman of this committee. I think we can agree that no one has worked
harder at the development of Common Lisp than Scott, and that we should
unanimously elect him chairman of the technical committee.
-rpg-
I second the motion.
--Guy
∂20-Apr-86 1444 FAHLMAN@C.CS.CMU.EDU Chairman
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Apr 86 14:43:29 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 20 Apr 86 17:46:08-EST
Date: Sun, 20 Apr 1986 17:46 EST
Message-ID: <FAHLMAN.12200430445.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Subject: Chairman
In-reply-to: Msg of 20 Apr 1986 16:32-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
I would like to thank Dick and Guy for the nomination and say that if
elected by the committee members, I am willing to accept this post
through, let us say, the end of 1986 (unless the committees get
substantially reorganized before then through interaction with X3).
Other nominations are certainly in order at this point.
-- Scott
∂21-Apr-86 1155 GRISS%HP-HULK@hplabs.ARPA Chairman
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 21 Apr 86 11:54:33 PST
Received: from HP-HULK by hplabs.ARPA ; Mon, 21 Apr 86 11:55:00 pst
Date: Mon 21 Apr 86 07:08:06-PST
From: Martin <GRISS%HP-HULK@hplabs.ARPA>
Subject: Chairman
To: cl-technical@su-ai.ARPA
Cc: GRISS%HP-HULK@HPLABS
I vote also in favor of Fahlman
M
-------
∂22-Apr-86 0903 FAHLMAN@C.CS.CMU.EDU Ballot: Fahlman for chairman?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Apr 86 09:01:05 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 22 Apr 86 12:03:30-EST
Date: Tue, 22 Apr 1986 12:03 EST
Message-ID: <FAHLMAN.12200892357.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Subject: Ballot: Fahlman for chairman?
Just to make it all official: The proposal is that Scott Fahlman should
serve as Chariman of the Technical Committee though 31 December 1986.
Please vote yes or no by Tuesday, April 29 at the latest.
Though Gabriel and Steele introduced and seconded the motion, I believe
that is not the same as voting yes on it. So far, then, we have what I
take as formal "yes" votes from Bobrow and Griss.
Fahlman abstains.
∂22-Apr-86 1116 RPG Vote
To: cl-technical@SU-AI.ARPA
I vote for Fahlman.
-rpg-
∂22-Apr-86 1153 ALAN@AI.AI.MIT.EDU Ballot: Fahlman for chairman?
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 22 Apr 86 10:27:43 PST
Date: Tue, 22 Apr 86 13:30:00 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Ballot: Fahlman for chairman?
To: Fahlman@C.CS.CMU.EDU
cc: cl-technical@SU-AI.ARPA
In-reply-to: Msg of Tue 22 Apr 1986 12:03 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[AI.AI.MIT.EDU].29870.860422.ALAN>
Yes.
∂22-Apr-86 2028 Moon@SCRC-STONY-BROOK.ARPA Ballot: Fahlman for chairman?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Apr 86 20:28:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 469884; Tue 22-Apr-86 23:27:35-EST
Date: Tue, 22 Apr 86 23:26 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Ballot: Fahlman for chairman?
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: cl-technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12200892357.BABYL@C.CS.CMU.EDU>
Message-ID: <860422232644.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Yes
∂25-Apr-86 1035 gls@THINK-AQUINAS.ARPA Ballot: Fahlman for chairman?
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Apr 86 10:34:54 PST
Received: from THINK-KATHERINE.ARPA by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 21410; Fri 25-Apr-86 13:39:13-EST
Date: Fri, 25 Apr 86 13:36 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Ballot: Fahlman for chairman?
To: Fahlman@CMU-CS-C.ARPA, cl-technical@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12200892357.BABYL@C.CS.CMU.EDU>
Message-ID: <860425133639.5.GLS@THINK-KATHERINE.ARPA>
Yes.
--Guy
∂27-May-86 0931 FAHLMAN@C.CS.CMU.EDU Where we stand
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 May 86 09:31:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 27 May 86 12:11:49-EDT
Date: Tue, 27 May 1986 12:10 EDT
Message-ID: <FAHLMAN.12210057807.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: cl-technical@SU-AI.ARPA
Subject: Where we stand
In-reply-to: Msg of 27 May 1986 10:24-EDT from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
I agree with both suggestions: to keep a separate file of changes and to
label each technical committee decision with a number and/or a date.
-- Scott
∂27-May-86 1016 DLW@SCRC-QUABBIN.ARPA Where we stand
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 May 86 10:16:20 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 2203; Tue 27-May-86 10:22:34 EDT
Date: Tue, 27 May 86 10:24 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Where we stand
To: Fahlman@CMU-CS-C.ARPA, cl-technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12209892202.BABYL@C.CS.CMU.EDU>
Message-ID: <860527102431.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 26 May 1986 21:01 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
technical committee would make a decision. Each such decision is folded
immediately into the manual, which is available online to everyone.
I'd like to suggest that in addition to folding in such changes, we also
maintain an official change history. This would serve as a summary of
all official decisions of the technical committee. It would help
someone answer the questions: (1) what has changed? (2) has there been
an official resolution of this issue?
To help make it clear that these decisions are final resolutions, so
that people can know when to modify their implementations and so as to
terminate trailing flames, I suggest that the changes be numbered
serially. I anticipate some reactions of the form "that's too
bureaucratic" or something, but I think it would save a lot of trouble
in the long run, in keeping the record straight.
∂18-Jun-86 0959 RPG OOP
To: cl-technical@SU-AI.ARPA
This committee might be interested in the activities of LMI.
They are on a road show to talk about a commercial standard OOP.
In particular, they seem to be interested in a kernel OOP
such that the things they want are implementable in it. The basic
flavor of their proposed kernel is CommonLoops, but with some stuff
to implement ObjectLisp. Eric Benson, Patrick Sobalvarro, and I
spent the entire day yesterday with them. The most interesting part
of the day was a discussion of the mis-merits of ObjectLisp.
The LMI folks are trying to arrange a meeting between themselves,
Xerox, and me to discuss this kernel idea. The key interesting point
is that LMI doesn't feel necessarily wedded to ObjectLisp - though they'd
like to retain the ability to have a `current object' - and that they
feel that the companies owe it to the world at large to make a decision
about OOP soon.
At Lucid, we are at the point of requiring an OOP for our own window
system, the case being that we have imlemented as much of it as we can
without making a committment to an OOP. We have flavors, but do not intend
to write our code using it. In the absence of a direction from the
community, we will simply adopt CommonLoops, though there will be a
Rosetta Stone phase in which we attempt to put down some documentation for
it by reading the code, talking to Gregor, and sacrificing chickens.
-rpg-
∂18-Jun-86 1055 FAHLMAN@C.CS.CMU.EDU OOP
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jun 86 10:55:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 18 Jun 86 13:55:21-EDT
Date: Wed, 18 Jun 1986 13:55 EDT
Message-ID: <FAHLMAN.12215843982.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: cl-technical@SU-AI.ARPA
Subject: OOP
In-reply-to: Msg of 18 Jun 1986 12:59-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
It has been clear to me since Boston that ObjectLisp was not a
contender. This is on its merits, and has nothing to do with which
companies have chosen to back it. When I describe ObjectLisp to people,
about 10% say "Hmmm...interesting" and about 90% make a sour face and
barfing noises. So I'm glad to hear that LMI insn't inseparably wedded
to this system.
In case I didn't say it clearly before, I'm now feeling pretty strongly
that what we want is a standard object-oriented system that is complete
enough to be usable on its own (but with some things available as
extensions) and not a set of hooks that will allow a thousand flowers to
bloom. It is now a bit late in the game for the idea of "let's put in
the hooks and experiment for a couple of years." As Dick's note
indicates, various groups are going to be locking in decisions pretty
quickly now.
-- Scott
∂20-Jun-86 0215 FAHLMAN@C.CS.CMU.EDU Guidelines
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Jun 86 19:44:02 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 19 Jun 86 22:43:55-EDT
Date: Thu, 19 Jun 1986 22:43 EDT
Message-ID: <FAHLMAN.12216202375.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-technical@SU-AI.ARPA
Subject: Guidelines
The following is essentially the "guideline" proposal that I sent around
before. Aside from Fry's opinion that we should do a lot of renaming
and argument shuffling in order to make the language more consistent, I
have heard no dissenting opinions. I would like to say that the
technical committee has accepted these guidelines. Please read the
following and let me know soon if you have any objection. Let's not get
bogged down tuning the language too finely on this, unless there's
something that really bothers one of you -- these are guidelines, and
not a contract.
-- Scott
---------------------------------------------------------------------------
As we develop a new language definition for Common Lisp, which we intend
to propose as an official standard, an important question is how much we
are willing to change the existing Common Lisp dialect, as described in
"Common Lisp: the Language". The following guidelines have been
accepted by the technical commitee:
Despite its imperfections, Common Lisp is already a standard. Nearly
every U.S. company with a presence in the AI market has announced some
sort of support for Common Lisp (though not always to the exclusion of
supporting other Lisps). There is similar interest in Japan among those
companies not totally committed to Prolog and some interest in Europe.
It is now our goal to turn Common Lisp from a de facto standard into an
official one. In the process, we have the opportunity to clarify those
things that are currently ambiguous (and which therefore weaken the
standard), to fix some problems that defeat the purpose of the standard
(e.g. problems that make it hard to write portable code), and to finish
defining some essential parts of the language that we left unfinished in
the rush to complete CLtL.
There are a number of implementations on the market, and many more in
the pipeline. There are many hundreds of active users, and this number
is growing very fast. A number of large software systems and AI
toolkits have been ported to Common Lisp, and again this is an
accelerating trend. All of this says that there is a very large
investment in the existing language; by the time a standard could be
approved, this investment will be much larger.
The existence of a large and fast-growing user community cuts two ways.
On the one hand, for every change that we consider, we must think about
not only the merits of making the change, but also the cost in terms of
code that must be changed and users who must be retrained. On the other
hand, if a change is unavoidable, the sooner we make it, the smaller the
cost.
Different kinds of changes have different kinds of costs:
Compatible extensions cost the users nothing (except that they make an
already complex language more complex). The cost is to the various
Common Lisp implementors who have to put the extension into their
respective products. If the extension is rather small, or if it will be
easy to implement (perhaps because someone supplies a public-domain
implementation of the extension), then we can consider the proposal on
its merits alone. If the extension requires some significant
implementation to make a lot of fundamental internal changes, then the
threshold is considerably higher.
In the case of true ambiguities (where implementors really have chosen
divergent interpretations, and not just where some clever fellow can
find a loophole in the language of CLtL), it is generally worthwhile to
make a clear choice, even though one group or another is going to have
to fix things. In some cases it will be appropriate to explicitly allow
both interpretations, but not where this tends to interfere with
portability of code.
Changes that affect a lot of existing user code should not be made
unless there are VERY strong reasons for doing so. Changes that would
break things in subtle ways are the worst -- something like changing the
type of NIL, for example, would break all sorts of things. Changes to
particular functions, which can be searched for by name and fixed in
straightforward ways, are not quite so bad. Changes to obscure corners
of the language that only concern a small minority of users are not so
bad, especially if the change benefits that small community and is
favored by them. For example, if there's some subtle issue about
roundoff that should be changed in order to make the number crunchers
happy, we could consider this.
In general, changes that affect only the implementors are less costly
than changes that affect all sorts of user code; there are fewer groups
that have to make changes, and they have more resources for doing so.
We must not overburden the implementors with changes or it will cause
delays and disruptions, and it could conceivably lead to a schism, but
we believe that a moderate number of small changes will not be resented
if the changes are made for good reason. From the time a change is
approved until the time it becomes part of some Official Standard will
be on the order of a year. That's plenty of time to make the changes
and to build and test a new version, even for the most ponderous of
companies.
There's a lot of interest in improving code portability, settling on a
workable error system, and trying to agree on an object-oriented
programming facilty (or foundation for one). If any of these goals
requires some change, that probably counts as a good reason. At this
point, mere aesthetic considerations are not sufficient to justify an
incompatible change.
∂20-Jun-86 0222 ALAN@AI.AI.MIT.EDU Volunteer
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 19 Jun 86 22:42:52 PDT
Date: Fri, 20 Jun 86 01:43:04 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Volunteer
To: RPG@SU-AI.ARPA
cc: cl-technical@SU-AI.ARPA
In-reply-to: Msg of 18 Jun 86 1002 PDT from Dick Gabriel <RPG at SU-AI.ARPA>
Message-ID: <[AI.AI.MIT.EDU].59350.860620.ALAN>
Date: 18 Jun 86 1002 PDT
From: Dick Gabriel <RPG at SU-AI>
I will do EVAL-WHEN.
I -think- I'm very interested in the EVAL-WHEN issues. They seem to be
related to a number of other puzzling problems that have been plaguing the
Lisp world recently, such as the problem of properly scoping the
identifiers returned by a macro, and the problems surrounding ``top-level''
forms. They all involve the ``meta-processing'' of a program.
As far as I know, no Lisp dialect has ever tried to be careful about the
code that describes this meta-processing. (Except 3LISP, which I suppose I
will go and look at again, but I don't recall that it seemed like a good
solution the first time I read it.) It would be nice if CL could get this
right.
Of course it may turn out that this can not be adaquately addressed within
CL, due to other constraints we have already built in to the language, in
which case I would be less interested. But I'm optimistic. Unlike the
EuLisp people, I think the CL evaluator is straightforward (boy are they
ever confused about -that-!), so I don't think that it will get in our way
on this one.
So, although I'm perfectly happy for you to get to work on this one,
if you would like to bounce something off of me early in your thinking, you
could be assured of my enthusiasm.
∂20-Jun-86 1145 ALAN@AI.AI.MIT.EDU Guidelines
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 20 Jun 86 11:45:41 PDT
Date: Fri, 20 Jun 86 14:45:54 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Guidelines
To: Fahlman@C.CS.CMU.EDU
cc: cl-technical@SU-AI.ARPA
In-reply-to: Msg of Thu 19 Jun 1986 22:43 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[AI.AI.MIT.EDU].59561.860620.ALAN>
I have no objections to the sentiments expressed in this document. Who are
these "guidelines" for? Is this a kind of press-release for the
consumption of users and implementors so that they will get a warm feeling
about the technical committee? Or is this a constitution we are adopting
that will be used in the future to guide our behavior and settle our
disputes?
∂20-Jun-86 1218 FAHLMAN@C.CS.CMU.EDU Guidelines
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jun 86 12:18:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 20 Jun 86 15:18:12-EDT
Date: Fri, 20 Jun 1986 15:18 EDT
Message-ID: <FAHLMAN.12216383375.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Cc: cl-technical@SU-AI.ARPA
Subject: Guidelines
In-reply-to: Msg of 20 Jun 1986 14:45-EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>
"Constitution" is a bit too strong, but I view these guidelines as
something that we or others in the design discussions can point to and
say "Look, this proposed change is too radical according to the
guidelines we have adopted." That doesn't mean we don't do it, but it
does mean that anyone proposing to violate the guidelines must make a
convincing case why it is justified. So the idea is more or less to set
a default level of conservatism that we all agree to, more or less.
Without this, we'd have someone like Fry arguing that we should
rationalize all the function names in order to make them look better.
-- Scott
∂21-Jun-86 1337 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Guidelines
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 21 Jun 86 13:36:17 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 26585; Fri 20-Jun-86 10:27:53 EDT
Date: Fri, 20 Jun 86 10:31 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Guidelines
To: Fahlman@CMU-CS-C.ARPA, cl-technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12216202375.BABYL@C.CS.CMU.EDU>
Message-ID: <860620103101.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Modulo fine-tuning of language, this looks fine to me.
∂24-Jun-86 1122 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Guidelines
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 24 Jun 86 11:16:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 28176; Mon 23-Jun-86 16:17:25 EDT
Date: Mon, 23 Jun 86 16:16 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Guidelines
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: cl-technical@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12216202375.BABYL@C.CS.CMU.EDU>
Message-ID: <860623161638.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
The guidelines you mailed out are okay with me. I think before
publishing this a bit more description of what it means in practice
for the cost of a change to be large or small should be included;
this would be something like a description of the process, where
"small" changes would be adopted easily if they have merit, whereas
"large" changes would have to survive some more elaborate process.
They way I've just described it is poor, and I don't think I would
agree with it myself if phrased that way. I think I saw a better
description go by in the mail in the past few days, but I can't
find it now. Perhaps you have it.
∂24-Jun-86 2026 FAHLMAN@C.CS.CMU.EDU Guidelines
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 24 Jun 86 20:26:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 24 Jun 86 23:25:54-EDT
Date: Tue, 24 Jun 1986 23:25 EDT
Message-ID: <FAHLMAN.12217520739.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-technical@SU-AI.ARPA
Subject: Guidelines
In-reply-to: Msg of 23 Jun 1986 16:16-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
The guidelines you mailed out are okay with me. I think before
publishing this a bit more description of what it means in practice
for the cost of a change to be large or small should be included;
this would be something like a description of the process, where
"small" changes would be adopted easily if they have merit, whereas
"large" changes would have to survive some more elaborate process.
They way I've just described it is poor, and I don't think I would
agree with it myself if phrased that way. I think I saw a better
description go by in the mail in the past few days, but I can't
find it now. Perhaps you have it.
I'm not sure what "better description" you might be talking about. I
thought that the definitions of "big" and "small" changes was spelled
out sufficiently in the guidelines, and that the only difference in
procedure would be the degree of reluctance that we technical committee
members feel in agreeing to changes. I trust us be duly influenced by
this. Do you really want this set up more formally?
-- Scott
∂05-Jul-86 2138 RPG Lisp Conference
To: cl-technical@SU-AI.ARPA
CC: rhh@MC.LCS.MIT.EDU
I think that the EuLisp people would like to meet with the Common Lisp
people on Tuesday night. However, Tuesday night is the night for the
speakers' and organizers' banquet, but I think that the Common Lisp/EuLisp
meeting should go on at the same time.
I might not be able to be there the whole time, but I can possibly slip
away after a speech and a quick bite. Bert Halstead is, I think, finding a
room for the EuLisp meeting, so we can use that room (?) If not, I can get
another (if MIT has none, Symbolics will).
The object-oriented programming meeting should take place around 2pm on
Wednesday. I'll ask Halstead to plan a room at MIT.
-rpg-
∂06-Jul-86 1447 FAHLMAN@C.CS.CMU.EDU Lisp Conference
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Jul 86 14:47:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 6 Jul 86 17:47:41-EDT
Date: Sun, 6 Jul 1986 17:47 EDT
Message-ID: <FAHLMAN.12220604896.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: cl-technical@SU-AI.ARPA, rhh@MC.LCS.MIT.EDU
Subject: Lisp Conference
In-reply-to: Msg of 6 Jul 1986 00:38-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
Dick,
The object-oriented meeting should be announced as soon as possible,
since it is open and since its timing after the end of the conference
may impact travel plans. I assume that you and Bert will announce
this meeting as soon as it is firm enough. If the time is now firm,
that could be announced in advance of finding a room.
-- Scott